The Modern Agile Organization

The Scrum Framework is not always Agile unless you make it — Photo by İrfan Simsar on Unsplash

How to empower self-ownership in teams, excellent software, and quick iterations

While this is an opinionated piece, the idea of Agile is to be able to adapt to the project’s needs and organize high-functioning teams.

What is Agile?

Agile isn’t defined by a set of ceremonies or specific development techniques. Rather, agile is a group of methodologies that demonstrate a commitment to tight feedback cycles and continuous improvement. — Atlassian

The Agile methodology tends to apply to projects and creative tasks at hand, whereas other businesses may be more privy to Lean management, which is great for repeatable operations and routine.

The Agile Manifesto was written in 2001 by seventeen individuals. They found consensus on 4 core values that are further explained with the 12 Agile principles. The whole object of Agile is to put the people first over the process and increase communications to foster a productive environment.

Agile Principles tldr:

Continuous Delivery of valuable software to end users
Welcome changing requirements
Business and Developers work closely
Build projects around motivated people and trust they will get the job done
Convey information within teams face-to-face
Working software is the measure of progress
Reduce burnout
Continuous attention to technical excellence and good design
Simplicity
Self-organized teams help emerge the best designs and architecture
At regular intervals, reflect on how to be more effective and tune behavior accordingly

Of course, this would not be an Agile blog if it did not mention the Scrum Framework. Scrum is a subset of the Agile process that is based around iterative software development cycles, with several key steps in the workflow — a daily standup, sprints (period of work, most seen is 2 weeks), sprint planning, sprint review, and sprint retrospective. A Scrum team consists of 10 or less people. To make an analogy, Six Sigma is to Scrum, as Lean is to Agile.

Before Agile was common, the Waterfall model was a popular way to manage projects. Waterfall consists of sequential processes, for example, the design and architecture of a feature is first, development work is “done”, it is handed to Ops, then from Ops to QA, and if bugs are found, return to development. Scheduled releases are when the features should be done and ready for live public use.

Pitfalls

Sometimes frameworks like Scrum are adopted to help establish processes and speed up software delivery, and sometimes these processes will go overboard and create burnout, slower deliveries, and mistrust.

During sprint planning meetings, it is a common practice to estimate the complexity of the ticketed work; however, some may conceive the ticket estimate (points) as time-based values. This then is used to “predict” feature readiness or delivery and can cause tension when things do not go as planned. Estimating’s primary purpose is to avoid developer burnout by ensuring work based on complexity is given to the most appropriately experienced individuals (junior engineers may not take an XL ticket).

Scrum prescribes certain meetings to take place during and before sprints, and Agile does focus a bit on communication; yet, this pattern tends to evolve into more and more meetings, where 80% of developer time is spent in meetings and 20% coding and designing.

Scrum can often lead to a misperceived balance of communication. The engineers on the development team should be trusted enough to predict how long it may take to build x feature and what it takes to build it. Without this trust or communication from engineers to stakeholders, unreasonable expectations and delivery dates, also known as a Crunch deadline, can happen more often than not, leading to developer burnout and cut corners.

The easiest way to avoid, or recover from, these pitfalls, is to take a step back from your processes and revisit the principles.

Making it Modern: Roles in Agile Teams

Much like Agile, the way teams adopt the philosophy is ever changing and really what matters most is what is productive for that team. The basic framework, adapted to a more modern approach prescribes:

Business Liaison (Product Owner) — As the Liaison, the job entails providing the business/stakeholders with insights on what the team has developed thus far and coordinating with the Agility Lead/Project Manager on what the priorities of the business are. Data should be utilized to help inform the development of new features and presented to the business to aid in decision-making.

Developers — The Developers on the team get the planned work done. This work may consist of system and application architecture, developing ML models, developing APIs (Application Programming Interfaces), creating UIs and even developing UI wireframes. Developers are responsible for figuring out how to build the application and establishing priority and estimated delivery dates with the help of the Agility Lead.

Agility Lead (Scrum Master) — The Agility Lead is also likely to be your qualified Project Manager. They help assist in running efficient meetings, establishing communication channels, arbitrating for the Liaison and the Developer Lead, and aiding in the visualization of timelines for deliverables.

Making it Modern: DevOps and NoOps Culture Adoption is Agile

Developer Teams

DevOps is an organization philosophy to help the adoption of Agile. In Waterfall models, Ops and Developers are separate teams and involve separate pieces of work; but with the DevOps philosophy, developers widen the area of responsibility as they not only handle the design and development of projects (left circle) but also own the process into the maintenance and observability phase (right circle). With this workflow, the people who built the project know it best and how it should run as well. This allows developers to catch bugs and performance issues earlier and iterate.

DevOps is a part of the shift-left culture, where the sooner you find issues the faster they are fixed and deliverables are better quality. In the verification phase, developer teams will write automated tests from the smallest testable code to how the feature or project integrates into the overall application.

Unit Tests (business logic, where a function should always add 2 numbers outcome should be expected)
Integration Tests (Behavior-driven is most common, if a user clicks — x should happen)
End to End Tests (E2E how the feature works in the application)

If your company can hire QA Testers, they can appreciate the added quality, while they try to find issues in newly released features outside of the sprint cadence your developers are working in.

Platform Teams

NoOps is a trending pattern that is the idea of fewer infrastructure Subject Matter experts needed on individual teams because the creation of infrastructure is instead approachable and user-friendly in design. The key to this is having Platform Teams!

Platform Engineering Teams consist of Backend, Frontend, and Infrastructure subject matter experts who create internal tooling that helps application teams create services and projects that adhere to company standards and self-service infrastructure tooling (you want a new Database provisioned, you just need to fill out a small form and click go). Platform Teams help set up UI libraries and Internal Developer Portals that keep a catalog of your projects in your software ecosystem, giving managers a holistic view of what teams are doing, costing, and what makes the applications!

Making it Modern: Organization Structure, Trust, and Empowerment Matter

[O]rganizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations. — Melvin E. Conway, How Do Committees Invent?

When it comes to organizing your engineering teams — let them do the work. Self-organizing teams allow the engineers to acquire the talent they need to build your products. The Engineering Lead of the team can work with their Engineering Manager, or in smaller companies this may be the same role, and either acquire the talent internally or, with the help of HR, externally. The team can then be responsible for a couple of different projects focused on business domains, for example in an e-commerce company, the team could be responsible for the checkout and navigation of the application. This will help build a decoupled system that can evolve as your business does.

Empower the individuals that are a part of the company and/or team. They may just have the next big idea to create a better product or feature. This entails trusting the engineers hired to actively want to build new features and projects as well as collaborate with them to help establish viable delivery timelines.

Agile methodology is easier said than done, and when implemented well, teams can deliver high-quality features faster. This is only a guide to help empower the creative process that is engineering applications.